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The present invention relates to a system and method for distributing 
benefits, and more specifically to an automated system and method utilizing 
smart cards for electronically distributing benefits to patrons. 

Purchase of mass transit fares has become more convenient with the 
implementation of fare cards that utilize an electronic chip to store value for 
credit/debit payment. Rather than fumble for bills and coins, the patron may 
simply touch the fare card to a fare gate reader. Reusable fare cards with 
read/write capability ajlow patrons to add time or value to payment-type fare 
cards, thus avoiding the inconvenience of having to carry currency, or, in the 
case of mass transit, exact change, for each transit use. 

Metropolitan transit authorities continue to improve their services to the 
public and private sector. Several transit authorities in conjunction with 
customers such as government agencies, welfare agencies, educational 
institutions, and private businesses offer transit benefits programs to patrons 
such as employees, students and welfare recipients. Although transit benefits 
programs are popular, current procedures are burdensome and largely unfunded 
within these organizations. Each year a transit authority must deliver millions of 
pieces of fare media to its customers, i.e. the agencies and institutions. Periodic 
delivery of the fare media requires use of an armored cars since the fare media 
has monetary value. Typical fare media utilized for transit benefits include paper 
cards with magnetic strips that function solely as a value-based card. The 
customers, in turn, distribute the fare cards to the patrons as either direct 
benefits or pre-tax benefits under certain tax benefits. 

The currently available fare cards are inconvenient for the patrons. 
Because the cards are typically issued as value-based cards, the patron cannot 
change the card to another card type without returning the card to a point of 
issue ("POP) device that is typically located at the transit authority. This 
requirement limits the patron's flexibility in receiving the best transit value for the 
benefit. Further, when a patron is due a refund or an adjustment, current 
procedures are manual and require the patron to restore value from a transit 
authority-issued fare card. As these benefits programs increase in popularity, 
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the administrative burden and patron inconvenience will increase. Thus, there 
remains a need for a convenient and cost effective means to provide, to 
distribute, and to add value to benefit credits for use in various applications 
including mass transit systems. 

5 

SUMMARY OF THE INVENTION 

It is an object of the present invention to provide an electronic distribution 
of benefits utilizing smart cards. 

It is another object of the present invention to provide a smart card that 
1 0 allows a fare type to be changed to another fare type without the need to return 
the card to a point of issue device. 

It is a further advantage of the present invention to provide a cost effective 
method to accomplish transit benefit downloads to a fare card. 

Still another advantage is provide a fare card that is reusable for periodic 
1 5 benefits distribution. 

Yet another advantage is to provide an efficient means for introducing 
benefits credits information into a data base utilizing a network terminal or a 
remote terminal connected to the data base by an Internet connection. 

The electronic benefits distribution system of an exemplary embodiment 
20 utilizes a central computer accessible via a local network or the Internet to 
maintain benefits credits of customers and their patrons. The value of a benefit 
credit is downloaded onto a smart card for use by a patron, i.e. the individual 
who is entitled to the benefit. In the exemplary embodiment, the benefit credit 
on the smart card is utilized for transit authority fees including transit fares and/or 
25 parking fees. However, the electronic benefit distribution system may be used 
for a variety of benefits distributions including welfare credits and food-stamp 
credits wherein a value credit is distributed to a patron by means of a smart card. 

Smart cards have found applications in many areas including pay phones, 
health care, banking, identity and access, pay television, gaming, metering and 
30 vending. Smart cards generally include one or more integrated circuit ("IC") 
located within the body of the card to receive and store information. The ICs can 
be read-only or have read/write capability. The smart card also contains 
interface means, which depend on whether the smart card is a contact-type or 
contactless smart card. The interface allows a computer system to add credit 
35 or subtract credit from a card. Contactless cards contain an antenna circuit for 
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communication with an RF source, whereas contact cards require physical 
contact of the magnetic chip or strip and a reader machine. 

In an exemplary embodiment, an issuing authority, e.g. a transit authority 
or a welfare agency, maintains a central computer for storing benefits 
5 information and downloading benefit values to a patron's smart card at vending 
machines. The customer is any organization that pre-authorizes benefits such 
as transit fares and parking fees. The customer is liable to the issuing authority 
to pay for those benefits. For example, a customer may be a public or private 
sector employer, a welfare agency distributing "Access to Work" benefits, or an 
10 educational institution providing benefits to its students. A patron claims the 
benefits and is the individual cardholder who uses the claimed benefits to pay 
the transit and/or parking fees. From the perspective of an employer, the patron 
is an employee. 

Benefits credits are pre-authorized by a user who has accesses to the 
15 benefits program system. The user may browse system screens to pre- 
authorize benefits or to administer the system. For example, the user may be 
a transit authority employee making an adjustment, or an individual representing 
the transit authority customer who is pre-authorizing benefits. In an exemplary 
embodiment, the transit authority maintains customer information and profiles. 
20 The system further allows the transit authority to administer customer user 
permissions and access so that, for example, one customer user is not allowed 
to alter or view the benefits of another customer's patrons. 

The benefits credit system of an exemplary embodiment allows multiple 
customer users to remotely maintain benefits data on the central computer 
25 utilizing their own personal computers and access through the Internet. 
Customer users are granted authority to view, add, change, update and hold the 
benefits of its patrons. The system of the exemplary embodiment further 
provides the customer with weekly and monthly reports via an Internet 
connection. 

30 In an exemplary embodiment a patron requests benefits at a transit 

express vending machine. The express vending machine is connected to a 
station monitor/controller that sends the request to the central computer of the 
issuing authority. The express vending machine waits for a response message 
from controller for a specified time. If no response is received within the 

35 specified time then the express vending machine declines the transaction and 
advises the patron. If the patron data storage tables in the central computer 
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contain one or more benefits for the patron, a single benefits response message 
is created and sent to the express vending machine. Each benefit associated 
with the patron is evaluated and approved or declined by the central computer 
utilizing a number of criteria including whether the benefit is expired, previously 
5 claimed, or in a hold status. If the benefit is unexpired, not claimed, and not in 
a hold status, the applications processor of the central computer puts a hold 
status on the patron benefit at the database. A hold status eliminates the 
possibility that duplicate benefits are processed at another express vending 
machine at the same time. In an exemplary embodiment, the message structure 
10 between the central computer, the station monitor/controller, and the express 
vending machine distinguishes between separate purses implemented on the 
same smart card. 

Once the patron's benefits are validated, a benefits response transaction 
is routed back to the station monitor/controller, which in turn routes the response 

15 to the originating express vending machine. The express vending machine 
acknowledges receipt of the response. When the station monitor/controller 
receives positive acknowledgment that the express vending machine has 
received the transaction it notifies the central computer. If the station controller 
cannot send the response to the express vendor, it notifies the central computer, 

20 and the benefits which were placed on hold, if any, are released. If the central 
computer does not receive an acknowledgment that the benefit has been 
dispensed, the benefit remains on hold. Central computer software applications 
ensure that the benefits are properly dispensed and that neither the issuing 
authority nor the patron is negatively impacted. 

25 If the benefits response transaction indicates that no benefits are 

available, the patron is so notified, and there is no requirement to return a 
benefits confirmation transaction. In an exemplary embodiment, a maximum of 
$200, including bonus amounts, is available for benefit download to a patron's 
smart card, assuming the current card value is zero. The express vendor and 

30 patron interface limits the allocated amount to ensure that the resultant card 
value remains within this limit. If the value of the benefits is less than the price 
of the fare medium selected, the patron may supplement benefits value with an 
approved debit or credit transaction, cash, a fare card trade-in or a combination 
of cash and a fare card trade-in. 

35 Once a benefit value is downloaded onto a smart card, a confirmation 

transaction message is sent through the station controller to the central 
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computer. The central computer then documents how, if at all, the benefits were 
used in the purchase of allowed fare product. The express vendor and the 
station controller must receive positive acknowledgment of receipt of the 
confirmation transaction before the transaction is purged from their respective 
memory buffers. Depending on the value authorized in the request transaction 
and the patron's selection, the express vendor may return unused portions of the 
request to the central computer to be used for subsequent claims. The central 
computer decrements the patron benefits values based upon the confirmation 
transaction, and releases the hold on the benefits. If the patron cancels a 
request or fails to select the option to load the requested value, the benefits 
confirmation transaction restores the benefits as unclaimed in the central 
computer benefits data storage. Once the benefit is depleted, the patron must 
add value to the smart card utilizing his or her own funds, or wait for a 
subsequent benefits period in which the customer replenishes the benefit value. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The present invention will be better understood from the following detailed 
description of a preferred embodiment of the invention, taken in conjunction with 
the accompanying drawings in which like reference numerals refer to like parts 
and in which: 

Figure 1 is a block diagram of the Electronic Benefits Credit Distribution 

System of a preferred embodiment; 
Figure 2 illustrates the Applications Processor functionality of a preferred 

embodiment; 

Figure 3 is a flow diagram of batch processing of a preferred embodiment; 
Figure 4 illustrates a request/response message processing of a 

preferred embodiment; 
Figure 5 illustrates a confirmation message processing of a preferred 

embodiment; 

Figure 6 illustrates late confirmation message processing of a preferred 
embodiment; and 

Figure 7 illustrates contingency confirmation message processing of a 
preferred embodiment. 



DESCRIPTION OF THE PREFERRED EMBODIMENT 
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Figure 1 illustrates the benefits distribution system 2 of the preferred 
embodiment. The system 2 utilizes a mainframe 4, or central computer, as a 
central point of operation within the organization of an issuing authority 36. In 
a preferred embodiment, a transit authority is the issuing authority 36 which 
5 operates the central computer 4 for the management of a metropolitan transit 
system. In alternate embodiments, the central computer 4 is located within the 
organization of an issuing authority 36 such as a government welfare agency. 
In a preferred embodiment, a transit authority 36 has administration 
responsibilities for the benefits distribution system 2. A transit authority user 14 

1 0 accesses the system 2 to pre-authorize benefits and/or to administer the system 
2. The transit authority user 14 maintains customer user 20, 22 information and 
profiles that are stored in a benefits data storage 6 of the central computer 4. 
A customer user 20,22 is an organization that pre-authorizes transit fare and 
other benefits for their patrons 24, and is liable to the issuing authority 36 to pay 

15 for the authorized benefits. The patron 24 is the individual who claims the 
benefits to pay, e.g., transit fares and/or parking fees. From the perspective of 
an employer, the patron 24 is an employee. In another embodiment, the patron 
24 of a regional welfare agency is a welfare recipient. Thus, the patron 24 is the 
individual holder of a smart card 30 who uses the benefits. 

20 The transit authority user 1 4 may enter and update customer 20, 22 data 

utilizing benefits system applications 10 that include web server applications, 
browser-based applications and central computer applications. The benefits 
system applications 1 0 allow the transit authority user 1 4 to administer customer 
user 20,22 permissions and access to protect against unauthorized accesses to 

25 the system 2. Permissions and access procedures also ensure that, for 
example, one customer user 20 is not allowed to alter or view the benefits of 
another customer 22. The transit authority 36 administration also includes 
"super-user" access that allows updating of any patron 24 benefit of any 
associated customer 20, 22. Updating may include adding, changing, deleting, 

30 or holding a patron account. A "hold" on a patron account occurs when credit 
may be available, but there is a reason to deny the patron 24 access to the 
credit. The super-user authorization provides a contingency service in an event 
that a customer 20,22 is unable to make changes to their patron benefits. In a 
preferred embodiment of the present invention, the transit authority 36 also has 

35 the capability to prepare and authorize an adjustment benefit type so that a 
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benefit credit of one type, e.g. a transit fare, may be converted to a parking fee 
credit. 

In a preferred embodiment, the transit authority 36 has the option to 
integrate the benefits data base 6 with the transit authority accounts receivable. 
5 Integration of the benefits data base 6 and the accounts receivable enables the 
value distributed to the customers 20, 22 to be tracked and updated 
automatically by the benefits system 2. Thus, a customer 20, 22 may request 
and/or access the amount owed to the issuing authority 36 at any time. 

The benefits credit system 2 allows multiple customer users 20, 22. 

10 Customers 20, 22 remotely maintain benefits data, including rail transit, parking 
and adjustment benefits, on the central computer 4 utilizing their own personal 
computer and access through the Internet 18 and web server 16. Manual 
distribution of personal computer software on floppy disk is not required for 
customer 20, 22 access and use of the benefits system 2. In a preferred 

1 5 embodiment, customer users 20,22 are granted authority to view, add, change, 
update and hold the benefits of its patrons 24. In an alternate embodiment, a 
customer user 20,22 has authority only to view patron benefits. The benefits 
distribution system 2 allows the customer 20, 22 to add benefits to any valid 
smart card 30 whether the benefits are provided by the customer or purchased 

20 by the patron. For example, and employee patron 24 may choose to have an 
amount deducted from his or her paycheck to be added to a monthly benefits 
allowance. 

The system 2 of the preferred embodiment provides a "global" 
maintenance capability for a customer level default of patron benefits. A global 

25 change allows a customer user 20, 22 to change their customer-wide default 
values. The global change of patron benefits of a first customer 20, does not 
affect the benefits of any other customer's 22 default information. The benefits 
distribution system 2 also provides a "maintenance by exception" function which 
allows the customer users 20, 22 to change individual patron parameters where 

30 customer-wide defaults do not apply. 

A patron 24 requests and receives benefits through interaction with an 
express vending machine 26. The patron 24 touches a smart card 30 having a 
unique serial number that is assigned to the patron 24 to the vendor target. 
Upon receipt of a smart card 30, the express vending machine 26 initiates a 

35 patron's 24 claim via a request message 32 to a station monitor and display 
system ("SMADS") 28. The SMADS 28 sends the request 32 to the central 
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computer, that, in turn sends a response notice of unclaimed and unexpired 
benefits. Upon receipt of a response 32 from the SMADS 28, the express 
vendor 26 downloads a benefit value to the smart card 30. The patron 24 then 
is able to utilize his or her benefits to pay for selected types of transit fare media. 

5 

Before the vending machine 26 transfers a monetary value to the smart 
card 30, the central computer applications 10 validate that the smart card 30 is 
eligible for the requested benefits. In a preferred embodiment, an invalid smart 
card 30 is simply returned to the patron 32 with an indication of insufficient value, 

1 0 for example, an indication of zero dollar value available. The benefits system 2 
of the preferred embodiment ensures that only those benefits that are 
authorized, unclaimed, unexpired and not in a hold status are allowed for 
download to a smart card 30 for the purchase of fare media. When a patron 24 
specifies a price of the fare medium being purchased, the central computer 4 

1 5 determines the value of the unclaimed benefits, and utilizes table driven logic to 
authorize all, part or none of the benefits to allow purchase of the selected 
medium. If the patron 24 does not specify a pass type with a known price, the 
express vending machine 26 and central computer 4 interface authorizes all 
eligible benefits. 

20 To prevent multiple claims of the same benefits, a smart card 30 cannot 

be used to claim benefits from more than one express vending machine 26 at 
the same time. This safeguard is implemented at the database 6, not at the 
express vending machine 26 or the smart card 30. The process of claiming 
benefits at the express vending machine 26 to purchase fare media incorporates 

25 contingency processing which is equal to that of debit/credit transactions. Such 
contingency processing, discussed in detail below and shown in Figure 7, 
minimizes loss of benefits data in the event of hardware or telecommunications 
failure. 

In a preferred embodiment of the present invention, all benefit types, such 
30 as rail and parking, are added to the unrestricted cash purse of the smart card 
30, or are used to purchase a transit pass. In an alternate embodiment, the 
system allows a requirement for placing benefit types, such as rail or parking 
value, on individual smart card 30 purses. In the preferred embodiment, the 
smart card holder, i.e. the patron 24, may change the type of issued pass. The 
35 functionality of the express vendor 26 allows the patron 24 to change the smart 
card's 30 pass type to any of the currently defined valid pass types. These pass 
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types include one day passes, rail short trip passes, e.g., passes good for 7 
days, and rail fast pass, e.g., unlimited rail only use for a specified period. The 
pass type change is initiated at the express vending machine 26 and does not 
require the smart card 30 to be returned to a point of issue 1 2 for exchange. The 
5 benefits system 2 allows a patron 24 to "toggle" between pass types while 
maintaining an unrestricted cash purse. Card type changes include toggling 
from a stored value regular fare to any valid pass type and changing from any 
valid pass type to any other valid pass type. When a smart card pass expires, 
e.g., a pass that is valid for a specific number of days from issue, the system 2 

10 applies a default condition of a stored value only card. In a preferred 
embodiment, the default is applied utilizing an operational mechanism at transit 
system entry gates that allows value stored in the unrestricted cash purse to be 
used when a smart card pass expires. Once the default selection occurs, the 
smart card 30 remains in a stored value mode until a new pass period is 

15 initiated. 

In a preferred embodiment, value placed on the smart card stored value 
purse continues to receive a bonus under applicable transit authority 36 rules. 
For example, the smart card 30 may be utilized for payment of cash value rail 
trips, parking fees or pass renewal but cannot be used to pay for a pass change. 

20 In a preferred embodiment, all pass related renewals or changes require new 
money in the form of cash deposited at the express vending machine 26, a 
benefits download from the central computer 4, a credit or a debit card 
transaction or a fare card trade-in. The benefits distribution system 2 further 
allows the express vending machine 26 to renew smart card passes before they 

25 expire. 

In a preferred embodiment of the present invention, the transit authority 
36 does not enforce tax or benefits regulations and is not liable as an enforcer 
of regulations. Thus, the benefits system 2 is free of edits or checks that may 
be perceived as enforcement procedures. However, in alternate embodiments 

30 wherein the issuing authority 36 is also the regulation-enforcing customer, the 
system 2 may include edits and checks of the patron profile, and may indicate 
the reason for smart card 30 rejection to the patron 24. 

In a preferred embodiment, a system application 10 provided by the 
issuing authority 36 allows a patron 24 to add value to his or her benefits smart 

35 card 30. This option is desirable for instances wherein the patron's 24 unclaimed 
and unexpired benefits are not sufficient to purchase the selected product. The 
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added value is provided either through the customer 20, 22 or is purchased by 
the patron 24. Patrons 24 may add value directly to their smart card 30 and or 
benefits value utilizing their own funds through the use of an express vending 
machine 26. Benefits may be supplement utilizing an approved credit 
5 transaction, an approved debit transaction, with cash, with a fare card trade-in, 
or with a combination of cash and fare card trade-in. The patron 24 is offered 
the option of receiving a printed receipt. A "banked" transaction results from a 
patron 24 presenting his or her smart card 30 to the target on the express vendor 
26, inserting money at the express vendor 26, and then walking away from the 

10 express vendor 26 without touching the smart card 30 to the target of the 
express vendor 26 a second time to upgrade the smart card 30 value. 
Incomplete or "banked" transactions are automatically sent from the express 
vending machine 26 to the database of the central computer 4 for later claim by 
the patron 24. Thus, the system does not require manual processing of benefits 

15 adjustments as in prior art systems. 

As illustrated in the flow diagram of batch processing in Figure 3, the 
credits benefits system 2 of the preferred embodiment tracks maintenance of 
patron benefits by customer 66 and patrom 64 for the purpose of auditing 
maintenance actions. In addition, fare media purchased using benefits claims 

20 54 are recorded by the central computer for the purpose of auditing the use of 
benefits. Referring to Figure 1, in a preferred embodiment, customer users 20, 
22 are given online access to the last six benefits authorized and claimed. In 
other embodiments, the benefits system 2 provides the customer with all 
transactions by a patron 24. In addition, reporting of benefit activity includes a 

25 monthly benefits/claims summary 82, as shown in Figure 3, of patron exit and 
parking transactions to allow the customers 20, 22 to monitor smart card 30 
usage, and to determine which, if any, patrons 24 did not claim their benefits. 
In one embodiment of the present invention, the report summarizes benefit use 
and does not distinguish benefits value deducted at the gate and parking lot 

30 equipment from the value originating from value added to the smart card by the 
patron using cash, credit, or debit. The system of the preferred embodiment also 
produces weekly accounts receivable ("A/R") reports 88 for the transit accounts 
receivable. The accounts receivable reports 88 list benefits authorized and 
benefits claimed. In a preferred embodiment, the monthly and weekly reports 

35 82, 88 are delivered electronically to the customers 20, 22. 
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Patron benefits, customer profiles, and user profiles information is stored 
in the central computer 4 in benefits data storage tables 6. Table 1 lists typical 
information that may be included in the storage tables 6 of a preferred 
embodiment. The lists are not exhaustive and may include additional 
5 information as deemed necessary for particular applications of the benefits 
distribution system 2. Patron benefits data is stored and retrieved according to 
a benefit identification that is associated with each patron 24. In a preferred 
embodiment, a smart card serial number that is unique to each smart card 30 is 
utilized as the benefit identification. As listed in Table 1 , the benefits data may 

10 include benefit value information, authorization information, hold information, 
purchase information, and miscellaneous information. Benefit value information 
includes the type of benefit, the benefit effective start date, the benefit expiration 
date, the value of the benefit, and an identification of the customer. 
Authorization information indicates the date and time the benefit was authorized 

15 and the identification of the user who authorized the benefit. Hold information 
indicates the hold status and the reason for the hold, the date and time the 
benefit was placed on hold, the identification of he user who paced the benefit 
on hold. Purchase information includes the date and time the benefit was used 
to make a purchase, the benefit amount used to make a purchase, the vending 

20 machine number and location where the benefit was used to make a purchase, 
the fare medium type that was purchased, and the total value of the purchase. 
Miscellaneous information may include the date when information was generated 
to support the accounts receivable reporting, and a source and value used to 
supplement a patron's benefit. 

25 Customer profile tables include customer identification, name, and 

address. The benefits coordinator information may include a phone number, 
name, facsimile number and e-mail address. The customer type field of the 
customer profile indicates whether the customer is public or private sector. The 
customer profile also stores information regarding the default patron benefit type 

30 and values. User profile tables include user identification, the customer 
represented by the user, access and update permissions, superuser access 
status, and optionally, a user name, address, phone, e-mail address, and 
facsimile. 
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TABLE 1 



PATRON BENEFITS 


CUSTOMER PROFILES 


USER PROFILES 


Benefit Identification 


Customer Identification 


User Identification 


Benefit effective date 


Customer name 


User name 


Benefit expiration date 


Customer address 


Customer reoresentina 


Value of benefit 


Coordinator information 


User information 


Customer Identification 


Customer type 


Access permissions 


Authorization date 


Default types and values 


Superuser access 


User ID who authorized 


Open 


Open 


Hold status and reason 






Date, time placed on hold 






User ID who placed hold 






Date, time benefit used 






Amount of benefit used 






Machine number 






Fare medium tvpe 






Total value of purchase 






Date info, aenerated 






Source for added value 






Open 







The system of the preferred embodiment of the benefits distribution 
system 2 includes an archiving ability. Specifically, the benefits and claims 
tables are archived to conserve disk resources. User and customer profile data 

25 stores are maintained online and do not require periodic batch archival. 

Figure 2 illustrates an applications processor 8 functionality of a preferred 
embodiment. Applications include benefit claim processing 46, benefit request 
48, benefit response 50 and benefits maintenance 52. When a patron 24 
initiates a benefits request at an express vending machine 26, the express 

30 vending machine sends a transaction request message, designated as EUB1 , 
to the station monitor and display system 28 which, in turn, transmits the request 
EUB1 to the central computer 4 as an input transaction message ("ITM") 40. 
The request message EUB1 initiates the processing of a benefit request 48 that 
looks up the requested benefit in the benefits table 58 and a benefits definition 

35 table 56. Upon determination of the status of a request as valid or invalid, the 
benefits response application 50 initiates the output transmission message 
("OTM") 42 of a response message EUB2 to the station monitor and display 
system 28, which in turn routes the response EUB2 to the originating express 
vending machine 26. The express vending machine 26 acknowledges receipt 

40 of the response and download of a request value onto a smart card 30 utilizing 
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a confirmation message, designated as EUB5. When the station monitor and 
display system 28 receives positive acknowledgment that the express vending 
machine has received the transaction, it notifies the central computer 4. The 
confirmation response message EUB5 initiates the processing of a benefits 
5 claim processing application 46 which updates the claims table 54 and benefits 
table 58 in the benefits data storage 6, and confirms that the benefits are written 
to a patron's smart card. The benefits maintenance program 52 allows a issuing 
authority user 14 or customer user 20, 22 to view and/or update benefits 
information. In a preferred embodiment, benefits are viewable by smart card 30 

10 serial number or by a customer identification. 

Figure 3 is a flow diagram of batch processing of a preferred embodiment 
of the present invention. Load Benefits 90 is a batch process that is intended 
to be run weekly. Load Benefits 90 reads data from the benefits data storage 
6 tables including an Enrolled Patrons table 60 as maintained by the customers, 

15 a Patron Benefit Eligibility table 62 as maintained by the customers, and a 
Benefits Definition table 56 as maintained by the issuing authority. The Load 
Benefits Process 90 creates data to be inserted as rows into the Benefits table 
58 where the benefits are available for claim by the patrons 24 using a smart 
card 30 at an express vending machine 26 (see also Figure 1 ). The criteria that 

20 must be met before the benefit creation in the Benefits table 58 includes a 
verification that a patron is enrolled and eligible, the effective date for the benefit 
is a current month or an earlier month, and a required lead date and time is met 
as explained in detail below. The Load Benefits process 90 produces a Load 
Detail report 94 that is used to determine the status of benefits processed. The 

25 report 94 indicates the results of the Load Benefits process 90 including 
successful insert in the Benefits table 58 and errors encountered. 

The Enrolled Patrons table 60 is read for all patrons eligible for benefits. 
In a preferred embodiment, status is recognized by the value "E" (enrolled) in a 
patron_status column of the Enrolled Patrons table 60. Patron status is 

30 controlled by the customer 20,22. The Enrolled Patrons table 60 also contains 
a benefits effective date that is controlled by the customer 20, 22. A customer 
20, 22 utilizes the effective date field to control the first month when a benefit is 
available to the patron 24. A patron 24 may receive benefits as long as the 
effective date is the same month or a prior month as the patron request 

35 processing date. If the effective date is in a future month, requested benefits are 
not downloaded to the smart card 30 for the patron 24 until that month is current. 
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A typical exception to this future month effective date rule may be when a 
customer 20, 22 selects the first of the month as the effective date. For 
example, if the effective dates for a monthly benefit are July 1 to August 1 , then 
a benefit request on June 15 is processed. A Load Detail Report 94 lists the 
benefit as "LOADED". If the effective date is later than July 1, then a benefit 
request on June 15 is not processed, and the Load Detail Report 94 lists the 
benefit as a "FUTURE EFFECTIVE DATE" and will list that future effective date. 
Continuing with this example, a kickoff date between July 2 and August 1 allows 
processing in July with effective dates of midnight at the beginning August 1 
through midnight at the beginning September 1. 

Each Enrolled Patron table 60 row is related to a patron benefit eligibility 
table 62 using a customer identification and a category type. The Patron Benefit 
Eligibility table 62 contains at least one, and may contain many rows, for this 
combination of customer identification and category type depending upon the 
benefit types which have been assigned to it by the customer 20, 22. Each 
benefit type is evaluated using the contents of an eligibility_status column. Only 
those benefit types containing E (enrolled) in the Patron Benefit Eligibility table 
62 are loaded to the Benefits table 58. The eligibility_status is controlled by the 
customer 20, 22. 

Each benefit type in the Patron Benefit Eligibility table 62 is related to the 
Benefits Definition table 56 using benefit_type as the reference. The Benefits 
Definition table 56 contains a Frequency indicator such as "M" for indicating a 
monthly benefit. If the Load Benefits application 90 encounters a unrecognized 
Frequency indicator, then the benefit is rejected and listed in the Load Detail 
Report 94 with an invalid Frequency message. The Benefits Definition table 56 
also contains a lead time number, controlled by the Transit Authority 36, that 
may be used to establish the minimum number of days lead time before the 
effective date of the benefit being created. For example, if the Transit Authority 
36 requires at least fourteen days lead time before loading a certain benefit type, 
and the effective date is July 1, the load must occur before June 16. If the 
benefit is rejected because of this check, the Load Detail report 94 lists a 
message that the load was later than the required lead time number date. 

Upon verification of all required data in the Enrolled Patrons table 60, the 
Patron Benefits Eligibility table 62 and Benefits Definition table 56, a row is 
inserted to the Benefits table 58 using information originating from one of the 
tables 60, 62, 56. In a preferred embodiment, the Benefits table 58 includes a 
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Carcl Serial Number, a Customer ID and Manufacturer Serial Number originating 
from the Enrolled Patrons table 60. A Benefit Type originates from the Benefits 
Definition table 56. An Initial Value of the benefit originates from the Patron 
Benefit Eligibility table 62 as maintained by the Customer. The Benefits table 
5 also contains a Last Authorization Sequence Number that is initialized with the 
value 0, a Load Date and Time that is the current run date and time of the batch 
process, a Remaining Value which contains the same number as the Initial 
Value Amount, an Effective date that is calculated as the first of the next month 
beginning at midnight, and an expiration date that is calculated as midnight 

10 beginning on the first of the month following the effective period. If the effective 
date in the Enrolled Patrons table 60 is later than the effective date, the benefit 
is not processed. Instead, it is inserted and effective for the next month. The 
Benefits table 58 also contains hold information including a Last Claim Hold 
Code (Vendor Hold) that is initialized with the value A (available), and a Hold 

1 5 Code (Manual Hold) that is initialized with the value 0 (available). Other columns 
which record claim request, authorization, and confirmation events are be 
initialized with appropriate values. The Benefits table 58 may further contain 
Update Action Code, Update Date/Time, and Update User ID columns for 
embodiments that provide benefit updating utilizing interactive screens. 

20 The Load Benefits process 90 also checks for a data base duplicate 

return code during the insert process to protect against inadvertent submission 
of a load job more than once resulting in duplicate benefits. A duplicate entry is 
defined as having identical values in the Card Serial Number, Customer ID, 
Benefit Type, and Effective Date fields. The Load Detail Report 94 prints a 

25 Duplicate Benefit message if a duplicate entry is encountered, and the benefit 
is not loaded to the Benefits table 58. Because Customer ID is used to define 
uniqueness, it is possible that the same smart card 30 may be used by one 
patron who collects benefits from more than one employer. Thus, a duplicate 
Customer ID, by itself, does not trigger a duplicate return code. 

30 Continuing with Figure 3, included in the load process job stream is an 

Accounts Receivable Report process 86 for generating an accounts receivable 
report 88 of benefits loaded for the purpose of invoicing customers. The 
Accounts Receivable ("A/R") report process 86 uses a range of load dates that 
is defined and varied using an entry in an Automated Fare Collection ("AFC") 

35 Reference Table 84 since fares may vary depending on the date of a benefits 
request. The Reference Table 84 is maintained by the Transit Authority 36. The 



[PATBKUIT00.B29] 




- 16 - 

Accounts Receivable report process 86 may also be submitted as a stand-alone 
job. 

The Benefits and Claims Report process 80 of a preferred embodiment 
creates a benefits/claims report 82. The report 82 lists claims matched with 
5 benefits and calculates the difference in values, if any, as Unclaimed Benefits. 
Unclaimed Benefits information may be utilized for possible credit to the 
Customer 20, 22. The benefits/claims report 82 includes data for benefits that 
have expired within a defined date range using an entry in the Reference Table 
84 as maintained by the Issuing Authority 36. The Report application 80 utilizes 

10 patron information from a Patron table 64, customer information from a 
Customer table 66, and information from the claims table 54. 

The batch Load Benefits process 90 also includes a Create Index process 
92 to create a benefits index file 96. The benefits index file 96 is used by the 
Benefits Maintenance screen 52, as shown in Figure 2, as an index to the 

15 Benefits table 58 to maximize screen response to a user's browse command. 

Figure 4 illustrates a benefits request and response message processing 
of a preferred embodiment of the benefits distribution system 2. A benefits 
request message EUB1 is initiated by a patron with a smart card 30 at an 
express vendor 26 and is transmitted through a SMADS 28 to the central 

20 computer 4. The preferred embodiment utilizes a fixed request value of $200.00 
which is a maximum amount that can be loaded onto a smart card 30 assuming 
an initial card value of zero. The fixed request of other embodiments may be 
specified by the issuing authority 36 or the customer 20,22 as shown in Figure 
1. Referring again to Figure 4, when the express vendor 26 transmits the 

25 benefits request EUB1, a timeout process is actuated. The timeout process of 
a preferred embodiment allows 44 seconds to receive a response EUB2 to the 
benefit request EUB1 before the express vendor 26 terminates the transaction. 
The timeout process timer of other embodiments may vary according to 
expected connection response time of a system 2. 

30 The benefit request message EUB1 contains the Last Authorized Benefit 

Sequence Number as it is read by the express vendor 26 from the smart card 
30. The Sequence Number is processed during the response message EUB2 
and is used by the central computer applications 10 when entering contingency 
benefits processing as shown in Figure 7 and explained in detail below. In a 

35 preferred embodiment, the central computer responds to the request message 
EUB1 with a MACKEUB1 STATUS=0 to indicate receipt of the request message 
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EUB1. However, regardless of the MACKEUB1 status, the express vendor 26 
continues the timeout processing. 

The correct response to the request message EUB1 is the benefits 
response message EUB2. If no response message EUB2 is received by the 
express vendor 26 when the timeout value expires, the express vendor 26 
advises the patron 24 that the transaction cannot be processed. If the response 
message EUB2 is received after the timeout has expired, the express vendor 26 
automatically generates a confirmation message EUB5 that contains an amount 
of $0.00 claimed. 

Upon receiving the benefits request EUB1 , the central computer 4 verifies 
the serial number 102 received from the express vendor 26 with the valid Card 
Serial Numbers listed in the Benefits table 58. If no benefit is found, the 
response message EUB2 contains a return value of $0.00 in a Requested Value 
or Price field. If one or more benefits are resident in the Benefits table 58, the 
benefit availability 104 is evaluated according to the benefit effective date, the 
benefit expiration date, the vendor hold status, and the manual hold status. The 
requested benefits are not processed if the Vendor Hold does not contain the 
value "A" (available). If the benefit is in Vendor Hold status (value ="N"), further 
logic is applied for the contingency that a confirmation message EUB5 was not 
received by the central computer 4 as illustrated in Figure 7. If the benefits are 
on Manual Hold, the response message EUB2 contains the value $0.00 in the 
authorized amount. 

Upon verification of benefit availability 104, the Purse or Class Identifier 
in the request message EUB1 is evaluated 106. Each benefit in the Benefits 
table 58 contains a Benefit_Type. That Benefit_Type is looked up in the 
Benefits Definition table 56 to ensure that the Purse or Class Identifier is valid 
for the Benefit_Type. For example, a value 128 is used for the General Use 
Purse of a preferred embodiment. The Benefits Definition table 56 contains a 
column titled Product_Purse_Rules. In the current example, position 128 of that 
column is evaluated. If that position contains T, the benefit is allowed for this 
type of product. If position 128 contains "N", the benefit type is NOT allowed for 
this type of product, and the response message EUB2 transmits $0.00 in the 
Requested Value or Price to the vendor 26. 

In a preferred embodiment, the Benefits Definition table 56 also contains 
a column titled Bonus_Rules. Similar to the Product_Purse_Rules, the column, 
of this example, is evaluated in position 128. If position 128 of the Bonus_Rules 
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in the Benefits Definition contains "1 the response message EUB2 contains "1 " 
in a "Bonus Flag" field and the express vendor 26 calculates an award bonus. 
If position 128 contains "0" in the Bonus_Rules column, the response message 
EUB2 contains "0" in the "Bonus Flag" field and the express vendor 26 does not 
5 award a bonus. In this manner, bonus calculation is controlled by a Benefits 
Definition table 56 in the central computer 4 and not with software logic i the 
express vendor 26. 

The benefit availability step 104 also determines the sum value of all 
benefits authorized, and returns the value in the response message EUB2. The 

10 sum does not exceed the amount requested in the request message EUB1 , and 
the maximum amount authorized in the response EUB2 is $200 forthe preferred 
embodiment, subject to the previously noted limitations. If there is more than 
one benefit contained in the Benefits table 58 for smart card 30, each benefit is 
evaluated separately for benefit availability 104 and benefit rules 106. 

1 5 If benefits are authorized 1 08, the benefit rows of the benefits table 58 are 

updated. The Last Authorized Benefit Sequence Number from the request 
message EUB1 , that originated from the smart card 30, is incremented by one 
and stored in the Benefits table 58. This value may be observed in a benefits 
maintenance 52 screen of a preferred embodiment. The central computer 4 

20 creates an Authorization Code and records this in the Benefits table 58. The 
Authorization Code also is contained in the Response message EUB2. The 
Authorization Code is later used to recognize a late confirmation message EUB5 
as illustrated in Figure 6 and described below. The Vendor Hold status is set to 
"N" to prevent the patron 24 from claiming benefits simultaneously at two 

25 express vendors 26. The first request message EUB1 is processed, while the 
second request message EUB1, as shown in Figure 7, returns $0.00 in the 
amount authorized because the benefit is in "Vendor Hold" status. 

Continuing with step 108, the "Last Request" columns are updated. 
Included in these columns are the "Request Type", which is the date and time 

30 of the request and the Retrieval Reference number which was generated by the 
vendor and transmitted in the request message EUB1. The "Last Claim" 
columns also is updated. This information includes the amount authorized in 
the EUB2, the date and time of the transaction, the Last Authorized Sequence 
Number and the Authorization code. This information is used in the "missing 

35 EUB5" scenario illustrated in Contingency Benefits Processing of Figure 7. The 
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Last Request and Last Claim columns are also observable in a benefits 
maintenance 52 screen of a preferred embodiment. 

The Benefits Response EUB2 is formatted and returned to the SMADS 
28 and express vendor 26 that generated the original benefit request EUB1 . The 
5 response message EUB2 contains the amount authorized and the incremented 
"Authorized Benefit Sequence Number." In the preferred embodiment, the 
station monitor and display system 28 responds to the response message EUB2 
utilizing a "MACKEUB2 STATUS=0". However, If the "MACKO" is not received 
by the central computer 4, the benefit status is not altered nor "reversed". Upon 

10 receipt of the Benefits Response EUB2, the express vendor 26 evaluates the 
message fields. The Response must match an EUB1 transmitted by the express 
vendor 26. The match criteria are Card Type, Serial Number, Retrieval 
Reference Number and express vendor Address. If the response message 
EUB2 is not matched, or the express vendor's timeout value has expired, the 

15 express vendor 26 returns a confirmation message EUB5 to the central 
computer 4 containing $0.00 in the "Requested Value or Price" field. 

Figure 5 illustrates a confirmation message processing of a preferred 
embodiment. If the response message EUB2 arrives at the express vendor 26 
within the timeout value and the response message EUB2 is matched with a 

20 previous EUB1 , the Vendor's panel displays the authorized amount. The patron 
24 may reduce the amount or cancel the transaction, but is not permitted to 
increase the amount. The express vendor 26 patron interface allows the patron 
to supplement value using debit, credit, cash or farecard trade in. However, in 
a preferred embodiment, the express vendor 26 may not increase the General 

25 Use Purse over a predetermined maximum value of $200.00. The express 
vendor 26 processes a bonus if the response message EUB2 contains a "1" in 
the Bonus Flag field. This value ultimately originated from a Bonus_Rules 
column in the Benefits Definition table 56. If the response message EUB2 
contains "0" in the Bonus Flag field, the express vendor 26 does not award a 

30 bonus. 

If the patron 24 cancels the transaction or the express vendor 26 receives 
no response from the patron, e.g., the patron walked away from the transaction, 
the express vendor 26 prepares a confirmation message EUB5 containing $0.00 
in the "Requested Value or Price" field. The confirmation message EUB5 is 
35 transmitted through the SMADS 28 to the central computer. 



[PATBKUITOO. B29] 



-20- 

When a patron 24 completes a benefits transaction, the smart card 30 is 
updated with the returned request amount and the "Authorized Benefit Sequence 
Number" as received in the response message EUB2. The express vendor 26 
then formats the confirmation message EUB5 and sends the message EUB5 
5 to the SMADS 28, which in turn sends the message to the central computer 4. 
The confirmation message EUB5 is a financial transaction that affects the 
patron's benefit value. For this reason, if either the express vendor 26 or the 
station monitor and display system 28 do not receive a correct message 
acknowledgment, the confirmation message EUB5 is stored indefinitely until the 

1 0 correct message acknowledgment is received. In the case of the SMADS 28 to 
central computer 4 interchange, the SMADS 28 does not delete the confirmation 
message EUB5 from its memory/disk files until it receives a MACKEUB5 
STATUS=0 from the central computer 4. 

The confirmation message EUB5 contains only the benefit amount 

1 5 claimed by the patron 24. It does return bonus amounts or amounts added by 
the patron 24 using cash, credit, debit or fare card trade-in. The benefit amount 
may be the entire amount authorized in the response message EUB2. However, 
if the patron 24 reduces the benefit authorization, or the smart card 30 General 
Use Purse exceeds a maximum amount, e.g., $200.00, by adding the full benefit, 

20 then the confirmation message EUB5 returns an amount less than that 
authorized in the response message EUB2. 

When the central computer 4 receives a benefits confirmation message 
EUB5, and the Authorization Code is not already in the claims table 54, it adds 
the EUB5 message data to the Claims table 54 for each benefit processed 122. 

25 Because it is possible for a single benefit to have many claims, the claims are 
distinguished by different Authorization Codes. The confirmation message EUB5 
also initiates an update procedure 120 of the Benefits table 58. The "Last Claim" 
values are updated including the Last Claim Amount as reported in the 
confirmation message EUB5, the date and time of the claim, the Authorization 

30 Code of the claim, and the vendor hold status is changed to "A" to indicate that 
the remaining benefit value, if any, is available to the patron. 

The update of the last claim values step 120 also updates the remaining 
value of the patron benefit. The claim amount from the confirmation message 
EUB5 is subtracted from the "Amount Remaining". The result is used to create 

35 a new "Amount Remaining." For example, if a patron 24 claimed all benefits 
available, the "Amount Remaining" is updated to zero. If the patron claimed $50 
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out of $120 available, the new "Amount Remaining" is $70. The amount 
remaining is available to the patron 24 until the benefit expires or is placed on 
hold. If the confirmation message EUB5 contains $0.00 claimed, for example, 
during a "walkaway" or patron cancellation, the entire amount indicated in the 
5 response message EUB2 is restored and available to the patron for subsequent 
claims. 

If there is more than one benefit found during confirmation message 
EUB5 processing, the "Amount Remaining" of the earliest benefit to expire is 
decreased by the claimed amount. If the amount claimed is more than the 

10 "Amount Remaining" in that "earliest to expire" benefit, the balance of the 
confirmation message EUB5 claim amount is subtracted from a remaining, or 
next to expire, benefit. 

Figure 6 illustrates a late confirmation message processing of a preferred 
embodiment. Processing of the confirmation message EUB5 incorporates an 

1 5 allowance for the contingency that delivery of a confirmation message EUB5 is 
delayed. Even though the confirmation message EUB5 must receive a message 
acknowledge status before it is released from the station monitor and display 
system 28, there may be an occasion when the confirmation message EUB5 is 
received by the central computer 4 after a patron 24 attempts to make another 

20 claim for remaining value. The confirmation message EUB5 includes an 
Authorization Code that was created by the central computer 4 during response 
message EUB2 processing. The Authorization Code is unique for each claim. 
Thus, when a delayed confirmation message EUB5 is received, the central 
computer 4 first verifies whether a claim has been processed by searching in the 

25 claims table 54 for the same Authorization Code 140. If a claim with the same 
Authorization Code is found in the Claims table 54, an adjustment claim row is 
created in the claims table 54 and the benefit balance is adjusted in the benefits 
table. If the authorization code does not match, then the central computer 
executes normal confirmation message processing 142 as illustrated in Figure 



Figure 7 illustrates a contingency confirmation message processing of a 
preferred embodiment. If the patron 24 requests a second claim before an 
confirmation message EUB5 for a first claim is processed, the central computer 
4 processing recognizes this condition by the presence of an "N" in the "Vendor 
35 Hold" column. If the confirmation message EUB5 has been received, the vendor 
hold column contains an "Y" . Thus, at least two scenarios may have occurred 
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if a second request EUB1 ' is made before receipt of a first confirmation message 
EUB5, that is, either the patron 24 received the benefits from the first ctaim or 
the patron 24 did not receive the benefits from the first claim. 

If the benefit is in a "Vendor Hold" status, logic determines whether or not 
5 the first claim was successful, i.e., the patron 24 received the benefits, by 
comparing a Last Authorization Code column in the Benefits table 58 with the 
"Last Authorized Benefit Sequence Number" in the second benefit request EUB1 ' 
as shown in step 1 30 of Figure 7. If the sequence numbers are the same, then 
the card's "Sequence Number" was updated, and the patron successfully 

10 completed the first claim at an express vendor "A" 26 . In this case, the logic 
defaults to creation of a claim in step 136, in lieu of the first EUB5, using the full 
amount authorized in the first benefits response EUB2. This processing is 
designed to handle a most probable situation wherein the patron claims and 
loads all available benefits value. If there is value remaining in the benefit, that 

15 amount is authorized in the second benefits response message EUB2* in step 
138. If there is zero value remaining, the second benefits response message 
EUB2' contains $0.00 authorized. If the patron reduced the first authorized 
amount in response message EUB2, then the value difference is not available 
until the original EUB5 is received and processed. 

20 For example, in a first most likely scenario, the patron claims all benefits 

value of $50. The patron is authorized $50 in a first response EUB2 and claims 
$50 to the card. The $50 value and a new sequence number is written to the 
card. The confirmation message EUB5 is not received at the central computer 
4. A subsequent request EUB1' by the patron for the full value $50 is received 

25 at the central computer with an equal sequence numbers. The missing 
confirmation message EUB5 is offset by the most likely situation of a full claim, 
and the second response message EUB2' authorizes $0.00. 

In a second example, the patron is authorized $50 and claims $20 to the 
card. The EUB5 is not received. A subsequent request EUB1' with equal 

30 Sequence Numbers creates a claim for the full $50. The remaining $30 is not 
available to the patron until the "missing" confirmation message EUB5 is 
processed. When that EUB5 is processed, a credit or $30 is restored to the 
patron in a delayed confirmation message processing as shown in Figure 6. 

In a second scenario as illustrated in Figure 7, the confirmation message 

35 EUB5 is missing and the patron has not received benefits from the first claim 
EUB1. If the benefit is in a "Vendor Hold" status and the last authorization code 
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in the Benefits table 58 does not match "Last Authorized Benefit Sequence 
Number" in the second benefit request EUB1', then the patron did not receive 
benefits from the first claim EUB1 at express vendor "A" 26. If a specific time 
period has elapsed, then the logic defaults to allowing the new request EUB1 ' to 
5 process. In the preferred embodiment, the processing utilizes a five minute time 
out as shown in step 132 of Figure 7. In this "missing EUB5" scenario, if five 
minutes have passed, the "Vendor Hold" is lifted and the new EUB1 Request is 
processed as if the first did not take place. If five minutes has not elapsed 134, 
then the response message EUB2' returns a value of $0.00. The five minute 

10 restriction greatly reduces the possibility that the patron is attempting 
simultaneous benefit requests from two vendors 26. 

An example of the second scenario occurs when the patron is authorized 
$50, but does not receive the value on the smart card 30. Since the value was 
not written to the smart card 30, then the sequence number on the smart card 

15 30 remains unchanged. The confirmation message EUB5 that should contain 
the received amount $0.00 is not received by the central computer 4. After five 
minutes, the full $50 is available to the patron under a second request EUB1'. 
There are no claims or adjustments required for the first EUB1 Benefits Request. 



20 received from the station monitor and display system 28, the confirmation 
messages EUB5 are rejected immediately by the central computer 4 processing. 
This feature is handled by database referential integrity which checks for 
duplicate rows in the Claims table 54. 



25 above by way of example only, it will be understood by those skilled in the field 
that modifications may be made to the disclosed embodiment without departing 
from the scope of the invention, which is defined by the appended claims. 



On the rare occasion that duplicate confirmation messages EUB5 are 



Although a preferred embodiment of the invention has been described 
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WE CLAIM: 



